Gekkan Dennou Club 147

home *** CD-ROM | disk | FTP | other *** search

/ Gekkan Dennou Club 147 / Gekkan Dennou Club - 2000.8 Vol. 147 (Japan).7z / Gekkan Dennou Club - 2000.8 Vol. 147 (Japan) (Track 1).bin / tools / pecls / diary1.doc < prev next >

Wrap

Text File | 2000-06-30 | 26KB | 460 lines

2000/6/30 5:07 色々悩んだ挙げ句、ハタと気が付いた。「unsigned short→unsigned int変換してから並べ替えたんじゃ、つじつまが合う訳ない！！」。つまり、 unsigned short [ab] → unsigned int[00ab] → Swap4[ba00] 全然ダメじゃん。と、言う訳でunsigned shortの状態でSwap()してから入れるようにする事で、なんとか動くようになった。ホントは時間があれば、cache.srv とかも入れたかったんだけど、もう時間が無いので諦めることにしよう。今回は、ソース一式もsnapshotとして公開するつもりなので、その辺も準備しないといけない。はたして、間に合うのか？ 2000/6/29 なんとか、dirコマンドが動作。しかし、ルートディレクトリィしか、ちゃんと表示されない。追っかけてみると、どうやらFAT値がおかしい。これは、明かにエンディアンの問題である。で、さっそくlowfnc.hで定義しておいたSwap2()マクロを使って補正したのだが、うまく動かない。困ったなぁ。昨日入れた画面クリアも動かないのが判っているので、そっちも直したいんだけど、時間が足りないかも。 2000/6/28 3:36 humanfs.srvのデバッグ。しかし、その為にはデバッグモードでチェックするのが一番手っとり早い。で、カーネルのデバッグ出力をIOCSコールを使用している部分を直接SCCを使用するようにする事で、デバッグモードを使用可能にした。ついでに、通信速度を9600bpsに変更。どうせデバッグモードと言っても、垂れ流しな訳なので、早いに越した事はないし。しかし、なぜか「/sys/server/humanfs.srv: [_stdio.writeId == NULL]」が表示される。で、よくよく考えてみると、標準入出力を初期化するUnixで言う所の initが存在しないので、pshでも独自にconsole.srvを初期化しているのを思い出した。けど、なんでhumanfs.srvが標準出力を使ってるんだ？調べてみると、やっぱりデバッグ出力・・・。そろそろデバッグ環境も見直す時期なのかもしれないが、時間が無いので後回し。取り敢えず画面に直接IOCSコールで出すことでデバッグを続行する。一応、iocs.drvのテストも兼ねる事になるのかな。ちゃんと動いているみたいではあるけど、まぁ、念のためだ。どっちにしろ、ちゃんとプリエンプティブになるまではiocs.drvの出番は無い訳だし。あと、console.srvでのESCシーケンスの処理を若干追加。やっぱり画面クリア位はサポートしてないと不便で仕方ないからね。 2000/6/27 4:23 iocs.drvは取り敢えず動いているようなので、今度は本命のhumanfs.srvの方に取り掛かる。コアになるFATやディレクトリィの読み取りルーチンは別途テストプログラムを作成して、テスト済みなので動くのは判っているのだが、これをサーバーにでっち上げる為には、このコア部分とサーバーとしてイベントループとの隙間を埋めるコードを書かないといけない。色々と思うところはあるものの、時間がないのでとにかく動くことを目標に進めて、なんとか実行ファイルを作成出来た。んが、まともに動かん。まぁ、コンパイルを通っただけのプログラムが一発で動く事ほど気味の悪い物はないので、別に問題はないけど、もうちょっと動く素振りを見せてくれると有り難いんだけど。シャープからHumanのシステムディスク等が公開されたので、こちらでもこれまでFLOAT2.Xの差分として提供していたfloat2.drvを、そのままディスクイメージに入れることにした。おかげで、インストーラ（？）が更に簡単になった。 2000/6/26 む～動かん。再びiocs.drvである。苦し紛れながら、_main.cを個別に持つことで、先日の問題はクリアしたハズなのだが・・・。デバッグモードにして実行経過を調べてみたが、特におかしな所は見当たらない。いいかげん諦めようと思った時に、フト思い付いた。「カーネル内のデバッグ出力はIOCSコールを使ってねーか？」と、言うことで取り敢えず、デバッグ出力を止めてみた所、あっけなく動作。結構悩んだんだけどなぁ・・・あと、ソースディレクトリィのdriver、server階層でのMakefileをちょっと効率化。 2000/6/24 先日作成したiocs.drvをテスト。しかし、なんか実行時エラーが出てしまう。はて？？？しかし、よくよく考えてみると、iocs.drvはpecls.knlの直後に起動される。なのに、標準入出力を司るconsole.srvを使って表示とかをしようとしていた。そりゃ、エラーになるわな。けど、そうするとラインタイムライブラリを使わずにiocs.drvを構成させる必要があるな。ちょっと面倒かも。 2000/6/21 将来的にHumanのエミュレートを行う時に必要になる、IOCSコールをマルチタスク環境で使用できるようにするために、iocs.drvを作成した。このiocs.drvを組み込む事で、IOCSコールをフックし、セマフォによる排他制御を行うようになるので、どのタスクからも任意の時点で呼び出す事が出来るようになる。ただ、現状では、pecls側で動作しているデバイスドライバとの整合性は考えられてない。ちゃんとやるには、IOCSコールに合わせてデバイスドライバへのメッセージに、置き換える処理を盛り込む必要が有るだろう。 2000/5/31 ちょっと本業の方が忙しかったので、手を入れられなかった。最近、本腰を入れてやってないので、だいぶ何をやっていたのか判らなくなって来ている。まぁ、その為にこれを書いてたりする訳なんだけどね。で、そうそう、seek処理を作成中だったのだ。このseek処理でファイルの終端方向(順方向)に移動するのは、問題無いのだが、ファイルの先頭方向(逆方向)への移動が曲者だったりする。 FATファイルシステムの特性として、順方向であればFATを辿れば移動できるのだが、逆方向への移動は無理なのだ。逆方向への移動が、どの程度の頻度で発生するかは判らないが、もし頻繁に使用されるのなら、内部的にファイルのFAT情報を配列に保存しておくと言う手が考えられる。しかし、この方法だとファイルサイズに比例してメモリーが必要になるからなぁ。取り敢えず、先頭から再スキャンするのが一番無難かな。 2000/5/12 更に間が空いて仕舞ったが、ちまちまと進行中。先日の状態だと、2階層以下のディレクトリィのファイルを、ちゃんとアクセスできなかった事が判ったので修正。まだ、サーバープログラムのスケルトンへの組込みと言う作業が残っているのだが、その前にファイルのseek/read/write処理を書かないとダメだな。 2000/4/19 なにやら妙に間が空いて仕舞ったが、なんとかファイルとディレクトリィのオープン処理が出来るようになった。ただ、マルチスレッド処理やイベントループへの組込みなどの部分は全然出来てなくて、フロッピーのイメージファイルをアクセスできるようになっただけなので、あんまり進んでないのは確か。もう少しまとまった時間を作って一気に仕上げたいんだけど、どうなることやら・・・ 2000/3/16 0:55 と、言う訳で、至ってシンプルな方式でファイルを検索する処理を作成。3時間程で、サブディレクトリィまで対応したファイルのオープン処理が、出来上がってしまった。実際には今回作った処理に1つ関数をかぶせて、一般ファイル用とディレクトリィ用とに分ける必要が有るけど、それ自体はすぐに出来るだろう。なんだかずいぶん時間が掛かってしまった様な気がするけど、なんとかhumanfs.srv の形が見えて来たぞ。 2000/3/13 どひー。humanfs.srvのデバッグの続きなんだけど、動かない原因が判明。なんと理由は単純で、「ルートディレクトリィは、FATにリストが無い！！」と言う半端な仕様が原因でした(涙) これって、ディレクトリィの管理はルートディレクトリィの場合は、絶対に別処理しないとダメって言う意味だよなぁ。ここまで作るまで気が付かなかったってのも間抜けだけど、こんな変な仕様にした方も悪いと思わない？・・・え？思わない？私が悪うございました。仕方無いので、根本的に処理手順を見直す必要が有りそう(涙) やっぱり、いきなり凝った事をしようとしたのが間違いの元かも。初心に帰って、「動く事」を優先にもっとシンプルな方式で取り合えず作り直す事にしよう。もったいないけど。 2000/2/24 loader.zでROMバージョンの判定が違ってたのを直した。それにしても、XVIcompact が1.2だとは知らなかった・・・。 2000/2/20 22:07 humanfs.srvのディレクトリィ内部リスト部分を作成。はっきり言ってFATベースの階層化ディレクトリィは効率的なキャッシュを行うのに向いてない。キャッシュを行わないのであれば、比較的シンプルにアクセス出来るのは確かなんだけど、階層の深いファイルをアクセスする場合は、各階層毎にキャッシュを管理しないといけないので、手間が掛かる。取り敢えず、基本構造は出来てきたので、後はそのリストを使ってのファイルの検索処理と消費メモリー低減のための効果的なキャッシュの解放処理だな。 2000/2/16 22:45 うーん。なんだか最近体力がなくて、仕事から帰って飯食ったら直ぐに眠くなってしまう。と、言う訳で全然進んでなかったりする。取り合えずはhumanfs.srv 周りのソースをちまちま直したりしているものの、全く成果として出てくるレベルにはなってない。humanfs.srvの基本的な関数はloader.zからの流用で行けるので、作り始めれば、そんなに手間は掛からないハズなんだけど・・・ 2000/2/9 8:56 フトしたことでEX68上で起動出来ないことが判った。原因はIOCSコールのB_READ の動作に違いが有るらしい。んが、詳しくは調べてない。もしかしたら、Human 以外のOSを起動出来るようには出来てないのかも。まぁ、この辺は気が向いたら細かく調べることにしよう。 2000/2/6 1:48 Humanfs.srvを書きつつあるのだが、FATやディレクトリィ情報のキャッシュを何処でやるかが問題である。少なくともFAT情報を全部メモリー上に持つのは、速度的には有利である物の、古今の大容量ストレージを考えるとおそらく無理である。ディレクトリィに関しては言うまでもなくメモリーには入りっこない。一番単純な手法は、Humanfs.srvとデバイスドライバの間にCache.srvを置いて、毎回ここに取得要求を出すと言う方法である。気になるのはタスク間通信のオーバーヘッドではあるのだが・・・。さてどうしよう。 2000/1/9 2:25 何故か気が付いたら年が開けていた。ホントは年末年始の休みを利用してデバイスドライバを組むつもりだったのだが、ツーリングに行ってしまい、そっちの方は全然手を付けられなかった。でも、scsi.drvの構想だけは立てたので、覚え書きとして書いておこう。 scsi.drvはSCSI-ID毎のスレッドとSCSI-BUSを制御するスレッドの二階層で構成し、SCSI-ID毎の受け付けスレッドからの要求を１つの制御スレッドのメイルボックスに送信し、制御スレッドから結果が帰ってくるのを待つ。これにより、１つのSCSI-IDに対して複数の要求を同時に処理しないようにシリアライズする事ができる（一次シリアライズ）。制御スレッドはメイルボックスから要求を取りだし、SCSIの制御を行う。ここで、処理が完結した場合は要求に対応する受け付けスレッドに結果を返して、次の要求の処理を開始する。更に、処理未完了で Disconnectが発生した場合（つまり一時的にターゲットがSCSI-BUSを解放した場合）は、メイルボックスるから次の要求を取りだし、実行する。処理完了後にReselectされた場合は、保留しておいた処理を続行して、結果が揃った場合は、受け付けスレッドに返す。これにより、SCSI-BUSの空きに合わせて複数のSCSI-IDに対する要求を処理できるようになる（二次シリアライズ）。と、まぁ、構想だけは打ち立てたのだが、正月ボケのせいか、全然開発が進まないのである。こういう時は焦らずに気力を貯めてからやった方が効率が良いので、充電しつつ構想を練ることにしよう。 1999/12/27 4:22 先日のミスを直してから、だいぶまともに動くようになってきた。でもって、これまで最大の謎であった（笑）Test UnitがCheck Conditionになる原因が判りました。SCSIの規格書を良く読んでみると、ターゲットは電源投入時や、SCSIリセット時には、パワーオン・コンディションと言う状態を保持しており、Request Sense で、最初に読みだす必要が有ったのでした。で、SCSIリセット後にRequest Sense を発行することで、その他のコマンド類も動作するようになりました。それから、マルチタスク環境で動作させる上で重要（かもしれない）Disconnect への対応なんですが、Reselectの発生を旨く検出出来ないのです。本来ならReselect 割り込みが発生するのですが、現状のテストプログラムでは割り込みは使用せずに、割り込み要因ビットをチェックしていたのだが、Reselectの時は、このビットが設定されないらしい。SPCのマニュアルをひっくり返して調べたところ、ネクサスの状態をチェックすることで、Reselectされた事が検出出来る事が判明。無事Disconnect/Reselectでやり取り出来る様になった。さて、この辺のノウハウを元にデバイスドライバにしてみるかな。 1999/12/25 21:03 昨夜からMach2のテストプログラムを書いているのだが、なんだか動きがおかしい。どーも、ステータスレジスタの値が変化しないみたいなのだ。色々調べたもののやっぱり判らずに、一度諦めて寝たのが11:00頃（爆）でもって、夕方頃に再び起き出して、NetBSDのソースとかと見比べてみたりして色々と試しているうちに、ふとSPCのレジスタアドレスが違うのでは？と言う疑念が・・・。で、調べてみたら0x00ea0080でないといけないところが、0x00ea080 になってる（爆）をい。まじですかぁ？余りにも情けなさすぎる(;_;) 1999/12/25 4:45 某SCSIの仕事の関係もあり、良い機会なのでMach2を借りることにした。満開ネットで貸し出してくれる奇特な方を募ったところ、某Y氏より借り受けることが出来た。で、早速バイクで受け取りに行ってテスト用マシンに装着。で、設定画面での設定可能項目を一通り見た後、簡単なプログラムを組んでROM を吸い出してdisる（爆）ROMなので、当然シンボルテーブルなんか無いので、最初は全然ソースにならない。なんか手間取りそうなので、こういう時の為に（笑）移植しておいたdis for FreeBSDでdisとラベルファイルの編集を繰り返す事、数時間。なんとかソースリストを得られた。この状態では内容はさっぱりなので、めぼしい文字列なんかから意味の有るラベルを付けていくと、割り込みの登録やら、IOCSコールの登録なんかを見つけられた。ここまで来れば、後はそのコール毎の処理を追っかける作業に入る。・・・と言う作業をやってました。別に遊んでた訳じゃないです。で、なんとかMach2p(なんとMach2ではなくMach2pが借りられたのです)に載っているMB86604Aのレジスタは0x00ea0080から32バイトに配置されており、純正やSACOMのSCSIボードレジスタとはアドレスが違うのである。ちなみに純正SCSIボードの石はMB89352で、レジスタは0x00ea0000からの32バイトなのだが、Mach2(p)の場合は、ここにアクセスするとバスエラーになるようになっている様だ。なので、ここを見れば外付けSCSIが純正かMach2(p)か判断出来る。更にROM内にはあちこちに「X680x0 Host Adapter mach2p」と言う文字列が出てくるので、ここの「mach2p」に「p」が有るかどうかでMach2とMach2pが区別出来るはずなのだ。と、言う訳で早速loader.zにその機能を組み込んでみた。それにしても最近、ここの１回の文書量が多くなってきているのは気の所為か？ 1999/12/18 1:50 先日の続きで、SCSIのテストプログラムを作成。Insideそのままのブロックを読み込むだけから、更にTest Unitを発行出来るようになった。ちょっとハマったのは、有りがちなgccの最適化によるやつで、 *HW_MB89352_INTS = *HW_MB89352_INTS; とやっている部分だったりする。MB89352のINTSレジスタは、割り込み要因を保持するレジスタなのだが、解除するためには、目的のビットを立てた値を入れる必要がある。要するにXORなので、同じ値を入れてやれば全部クリア出来るのだが、gcc -Oだと、見事に最適化でその行を削除してくれたのです。判ってはいたんだけど。で、例によって、 *HW_MB89352_INTS = *((volatile unsigned char*)HW_MB89352_INTS); と、直すことであっさり動きました。で、次にRead Capacityにチャレンジしたのだが、どうもうまく行かない。コマンドフェーズまでは動いているのだが、データインフェーズでフェーズエラーになってしまう。はて？何が悪いのだろう。もう少し調べてみる必要が有りそうだ。 1999/12/15 1:52 humanfs.srvもやらないといけないと思いつつ、某SCSI機器の仕事の絡みも有って、scsi.drvの方の基礎研究にも手を出すことに。いきなりドライバにするのは例によって、なかなか難易度が高いので、まずはテストプログラムを作ることにする。なにはともあれ、困った時のInside頼みと言うことで、InsideX68000を参考にテストプログラムを作成してみる。うーむ。MB86604とMB89352は、かなり違うなぁ。どっちかと言うとMB89352の方がシンプルで、扱い易い感じがする。まぁ、確かに形式が違うんだけど、同じ富士通のSPCなんだから、なんで同じI/Fにしてないの？理解に苦しむなぁ。それはともかく、このテストプログラムでノウハウを得て、scsi.drvと某SCSI機器で活用する予定である。あと、scsi.drvだが、純粋なSCSIの制御とチップの制御を分離しようかどうかを考え中。分離するとしたら、MB89352.drvとscsi.drvの組み合わせか、MB86604と scsi.drvで使用する事になる。この場合、scsi.drvは共通で使用出来るので、一応メリットは有る。さて、どうしたもんか。 1999/12/09 21:00 やはり、いきなりhumanfs.srvを作成するのは、色々と問題があるため、そのための基礎研究として、FATファイルシステムのアクセスを行うテストプログラムを作成する事にした。手始めに、先日検討したメモリー上でのデータ構造を単体のヘッダーファイルに分離。それから、FATのアクセスとデマンド・ローディング処理を書いてみた。面倒な処理になりそうだったFAT12でのページ境界でのセクタ番号の取り出しも、FATブロックのアクセス位置から必要なFATセクタを読み込むような処理にすることで、解決出来た。それから、フト思い付いたのだが、新にプリエンプティブになった時には、 float2.drvが問題になりそう。まだ、詳しくは見てないが、float2.drvはリエントラントでなかった様な気がするので、float2.drv入り口でセマフォでも付けて、排他制御する必要があるな。そのうちやることにしよう。 1999/12/02 3:38 humanfs.srvの続き。と言うか、根本から見直し。手始めとして内部のデータ構造のためのtypedefを定義。散々悩んだ挙げ句の答えは、内部データと読み込んだデータを両方保持する形式とした。でもって、FATの読み込み部分を書いてみた。それにしても12ビットFATの扱いって面倒。特にセクタ毎に別ブロックとして管理してしまったので、ブロックとブロックとの境界部分は特別扱しないといけない。なんか良い手はないもんか。 1999/12/01 2:46 LEVEL 4 はっきり言ってhumanfs.srvの方は、全く目処が立たないので、一度リリースすることにした。ただ、そのままだと流石にアレなので、最後のあがきとして、ローカル・ヒープに対応した。ただ、ローカル・ヒープは、足りなくなるとタスクが動かなくなってしまうので、ホントはマルチ・ヒープで有ることが望ましいと思う。なので、この辺の詳細は暫定仕様と言う事になるのかな。なにはともあれ、有る程度安定動作するようになったので、PECLS LEVEL-4をリリースします。前回のLEVEL 3からは約3ヶ月ぶりなのに、見た目も中身もあんまり変わりばえしてないのが情けないっす。 1999/11/28 0:05 ここ数日別件（笑）で忙しかった、と言うか追い詰められていたので、こっちの方は全然手を入れてなかったりする。でも、一応、構想だけは考えてました。で、一番の悩み所はやっぱり現在作成中のhumanfs.srvのデータ構造である。 Human68kのファイルシステムは、基本的にMS-DOSと同じなFATによるファイルシステムなので、FATとディレクトリィの管理が必要で、尚且つディレクトリィについては階層化されている。これらの情報を独自の内部形式で保持すると、メモリー的に不利だし、クラスタ単位に整合すると言う面倒な作業が出てくる。更に、既に削除されているファイルに対するディレクトリィの痕跡は、FAIL SAFE として出来るだけ残しておくことが好ましいのに、それも困難になる。逆にディスク上の形式そのままで保持する場合は、ディレクトリィ階層を保持するのが困難。と言うか内部的に欲しい作業領域を取る余地がないので、なんか面倒な事になりそうなのである。それから、ファイルサーバーはファイルのオープン毎に別スレッドを起動する事で効率的に動作させる予定なので、マルチスレッドで動作する様にしておく必要がある。なので、内部データ構造はマルチスレッド下でも破錠しないような形式または、破錠しないような対処が行える形式である必要がある。と言う訳で、長々と書いてしまっているが、難しい問題が有るのである。さて、どうするかなぁ・・・ 1999/11/23 1:25 humanfs.srvの、と言うよりはPECLS OSのファイルサーバー汎用のパケットを検討したのだが、以外とめんどくさい。一応、ユーザーサイドからはHuman FSでも、 PECLS FS（独自で作成する予定）でも区別する必要が極力無いようなファイルシステムを目指しているのだが、欲張った分だけ色々と考慮することが増えてきてしまった。なので、humanfs.srvが動き出すのは結構手間取りそうな予感である。一応、仮仕様でディレクトリィ一覧が出来るまで持っていってL-4をリリースするつもりだが、そこそこの機能を盛り込んだhumanfs.srvが動き出すのは、年内一杯掛かる気がする。それにしても、１年掛けてこの程度とは、我ながら情けない開発速度である。能力が足りないのもそうだけど、寄る年波には勝てないと言うことか？（笑） 1999/11/22 0:10 ふと思い立って、humanfs.srvに手を付け始めた。とは言ってもFATファイルシステムについては、loader.zで既に前例があるので、そこから殆どの処理を持ってきて手直しすることで、主な部分は作成出来た。んが、ファイル名、ファイル属性の扱いやら、マウントポイントの問題があるので、まだまだ完成には程遠いのだけど。特に、マウントポイントに関しては、name.srvにも関係することなので、仕様をどう決めるかが問題。おっと、ファイル名やファイル属性もFATファイルシステム専用でなくて、他のファイルシステムでも共通で使用出来る様な形式にしないと、サーバーにした意味がないので、この辺も悩み所だな。さて、humanfs.srvだが、ちゃんとしたものが出来るのには、まだまだ時間が掛かるので、ディレクトリィ一覧が取れるようになったらL-4のリリースをすることにしよう。なんとか、11月中にリリースしたいな。 1999/11/21 1:00 ついに原因を突き止めた。前にも書いたが、やっぱりメモリーの未初期化が原因だった。まぁ、単純に言うとタスク情報領域のwup_tsk()の回数を覚えておく変数領域を初期化していなかったために、起こされるハズのないslp_tsk()がSLEEP せずに起床して仕舞ったため、念のために入れておいたexd_tsk()を実行して仕舞っていたのでした。で、exd_tsk()は、まだ実装してなかったので、未実装コール呼び出しの、エラーが出ていたと言う訳。やっぱり、判ってしまえば単純なミスなのでした。と、言う訳でメデタクpshまで動くようになりました。loader.zでのSCSIボードの存在チェックが不十分だったのを修正。それと、MIDIボードのチェックも追加してみただいぶ延期されていたけど、PECLS-L4のリリースを考えることにしよう。問題は、何処まで盛り込むかだな。 1999/11/16 22:00 例によって動かない（涙）と、言う訳でちまちまとMakefileなんぞを整理してみる。調子に乗ってカーネルのbuild数を追加してみた。これまでの構築回数は覚えてないので、今回がBuild numberの1と言う事になる。それにしても、なんで動かないんだろう。ん？？？そー言えば、pshって随分長いことmake掛けてなかったなぁ・・・っても、別に何かを変えた訳じゃないので影響はないハズなんだけど、一応念のためチェックしてみるか。 1999/11/15 0:03 で、RAMチェックしてみました。もちろん正常。って、ゆーかぁー、Human68kが動くんだから正常に決まってるんだけど（笑）それはともかく、ブート・シーケンスを再検討していて、ふと気が付いたことがある。それは、ローダーを自己再配置の.r形式から.z形式に変更したのだが、それだとbss領域が初期化されないのである。と、言う訳でipl.rにbss領域の初期化処理を入れてみたのだが、結果は同じ（涙）一体何処が問題なんだろう？？？それにしても、最近この手の原因不明のバグに悩まされっぱなしだなぁ。困った困った・・・ 1999/11/14 0:56 なんとなく動かない現象が見えてきた。少なくとも割り込みは無罪らしい。だって、割り込みを使用しないカーネルでやっても同じ現象なので（笑）で、現象だけど電源投入後、数回の起動でだけfloat2.drvの組み込みで、未定義システムコール呼び出しのエラーが発生する。これは恐らくと言うかほぼ間違いなく初期化してないメモリーをアクセスしているバグであろう。でももし、バグでないならハード的にRAMが不安定と言う事になってしまう。うーん。バグなんだろうなぁ。できればそう願いたいのだが。 1999/11/13 0:38 なんかMakefileがごちゃごちゃしてきたので、GNU makeの拡張機能と思われる include機能を使って共通部分を共有する様にした。それと、原因は不明だが、何度もインストールを重ねたFDだと、refreshしても動作が不安定になるので、 FDのフォーマット＆インストールを簡単に行うために、FDに入れる配置のディレクトリィを作成した。どっちにしろ、システムのディレクトリィ構成なんかもちゃんと決めないとだめだな。まぁ、ファイルサーバーが動くまでは、それ程急がないけど。 1999/11/5 23:02 色々デバッグコードを入れてみたり、コンパイルし直してみたりしているうちに動くようになってしまった（爆）でも、安定して動く訳じゃ無くて、立ち上げる度に動いたり動かなかったりなので、どっかタイミング的にマズイ所が有るのだろう。この手のタイミングの問題ってのは、見つけるのがなかなか難しい。なんと言ってもスナップ・ダンプやデバッガとかでは見つけることが出来ないので、ソースとじっくりお見合いするか、設計に問題がないか検討すると言う地味な作業をやらないといけない。感じとしては、key.drv、text.drv、console.srv周りの初期化タイミングが怪しいのだがどうだろう？って、この手の予測は当たった試しが殆ど無いので、あんまりアテにはならないんだけど(^^;; 1999/11/4 3:24 なんか非常に久しぶりなので、何処までやってたのかさっぱりである。と、言う訳で適当にmakeかけてFDに実行イメージを作って動かしてみると、未定義コールを実行したとか言って止まってしまう。はて？なんか変えたっけ？？？どっちにしても、float2.drvは手を加えた記憶も、手を加える必要もないので、問題があるとしたら、pecls.knlか、loader.zのどちらかしかない。どっちかと言うとloader.zの方が怪しい気がするので、もうちょっとみてみよう。 1999/10/13 0:43 うーん。何処がおかしいのだろう。いつのまにかキー入力が出来なくなってしまった。見当としては、key.drvのキー入力イベントの生成スレッドだと思うのだが、どう見ても合っている様に見える。と、言うことはカーネルか？？？どっちにしても、もっと突っ込んで調べてみないと駄目だろうな。と言う訳で３歩進んで２歩下がると言う事を繰り返しているので、全然新しい機能に進めないのであった（涙） 1999/10/12 9:38 昨夜はフェスタ68の手伝いの疲れの所為か、この開発記を書き掛けのまま忘れて寝てしまった。と言う訳で、仕事に行く前に残りを書いていたりする。プリエンプティブになるまでは、ディスパッチを禁止してもあんまり意味がないのでテキストドライバのdis_dsp()/ena_dsp()をコメントアウト。 loader.zで、SCSIの装備状態を表示する様にした。これは、scsi.drv作成時まであんまり意味ないかも。ただ、Mach2pの量産が近い様なので、あんまりゆっくりもしてられないな。 slp_tsk()で既にwup_tsk()が発行されていてもSLEEP状態になっていたバグを修正。これによりタイミングによってはkey.drvが動作しなかった。そろそろ、PECLS-L4を放流したいので、ちょっとまとめを始めた。ん？もうこんな時間だぁ！！ああっ遅刻してしまう！！ 1999/10/6 0:42 テスト用マシン(EXPERT)の修理に失敗。おかげでPECLSのテストのための開発マシンをいちいち再起動しなくてはならなくてタルすぎる。これはとっとと電源を買ってくる必要があるな。タスクのスタートアップでグローバルヒープとメッセージ用のヒープIDを受け渡す様にした。タスクの異常終了なんかを考えるとタスク間でやり取りされるメッセージのためのメモリーは、タスクローカルから取るのは好ましくないので、グローバルヒープから取れる様にするため、グローバルヒープのIDを受け取る様にした。ただし、単純にグローバルヒープにした場合は、ヒープの断片化が心配なので、メッセージ専用のヒープを持つことを考えている。あと、そろそろPECLS-L4のリリースも考える必要があるなぁ。9月はあんまり時間が取れなかったので殆ど進んでないので10月末に持ち越すかな。 1999/10/5 0:11 余りにもファイルがデカくなってきたのでファイルを分けることにした。なんか開発記じゃなくて雑記帳になりつつあるような気もしないでもないけどまあいいや。読んでる人もあんまり居ないだろうし。先日のloader.rの再配置処理の撤廃は完了した。loaderはCで書いてある関係上、 .r形式にするのはめんど過ぎるので、.x形式にしようと思ったが、どうせ固定アドレスで動かすのなら、再配置テーブルとか読み込むのは無駄なので、.z形式と言うことで落ち着いた。 .z形式で$c0000からとは言っても、.z形式のヘッダが付いたまま直接$c0000に読み込むので実際の実行イメージは$c001cからと若干変則的になっている。注意されたし。それにしても1台のマシンで開発＆テストをするのは効率が悪すぎる。さっさとヒューズを買ってくることにしよう。